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ABSTRACT 

The  following  paper  describes  the  syntax  and  semantics  of 
a  language,  called  TESLA,  designed  to  easily  specify  the  control  of 
logic  simulations  on  a  hardware  level.   The  implementation  on  the 
B5500  of  a  translator  from  TESLA  to  an  input  language  to  the  ILLIAC  IV 
Control  Unit  Logic  Simulator  is  documented  in  detail. 


Ill 
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1 .   INTRODUCTION 

TESLA  is  a  simple  test  step  oriented  language  designed  to 
allow  a  simulation  user  to  take  advantage  of  the  full  range  of  simula- 
tion capabilities  offered  by  the  ILLIAC  IV  Control  Unit  Logic 
Simulator  System^  while  keeping  coding  as  simple  as  possible. 

A   quite  general  simulator  system  for  synchronous  logic  has 
been  designed  and  implemented  by  Luther  Abel  and  Chiyozl  Tanaka. 
Specific  implementational  details  (e.g.^  data  formats)  have  been 
oriented  towards  simulation  of  both  printed  circuit  cards  and  entire 
functional  sections  of  the  ILLIAC  IV  Control  Unit.  A  companion  test 
step  control  language,,  TESLA^  was  developed  to  control  the  simulation 
of  arbitrary  configurations  of  logical  elements. 

Each  interconnected  group  of  logical  elements  (e.g.,  a  card) 
may  be  considered  as  an  entity  in  the  middle  of  a  particular  environ- 
ment represented  by  the  inputs  and  outputs  to  the  card.   This  is 
summarized  in  the  following  diagram  (Minsky  [1]). 


Environment 


In  a  simulation  one  must  not  only  simulate  the  entity  under 
consideration  (the  card),  "but  one  must  almost  always  simulate  the 
environment  also,  at  least  in  some  minimal  manner.   For  example,  the 
electrical  signals  which  are  the  actual  inputs  to  the  card  are  not 
also  used  as  inputs  to  the  simulator,  but  rather  some  logical  or 
numerical  representation  of  them  is  used.   Further,  the  actual 
environment  consists  of  other  actual  cards,  while  in  the  simulator 
environment  it  is  only  necessary  to  provide  the  simulated  inputs  by 
any  convenient  means,  while  the  outputs  interact  with  the  environment 
almost  always  through  the  intervention  of  a  human  observer.   Since  a 
card  is  in  general  an  arbitrary  collection  of  arbitrary  interconnected 
logical  elements  rather  than  a  complete  functional  unit,  the  descrip- 
tion of  its  relationship  to  its  environment  and  meaningful  description 
of  inputs  and  outputs  becomes  a  non-trivial  task.   It  is  to  this  end 
that  TESLA  was  developed. 

The  arbitrary  collection  of  logic  mentioned  above  may  be 
represented  in  a  more  general  manner  by  the  model  shown  in  Figure  1 
(Hennie  [2]). 

It  is  obvious  from  the  above  figure  that  there  exist  major 
areas  which  can  be  controlled  in  a  logic  simulation: 

input  values, 

storage  (or  delay)  element  states, 

output  presentation  or  usage. 


Memory  (or  delay) 
Elements 


Figure  1.   Diagram  of  a  General  Logic  Circuit 


Therefore  TESLA  was  designed  to  provide  these  three  different  types 
of  controls  as  the  inputs  to  the  simulator,  along  with  additional 
facilities  to  even  further  simplify  the  logician-programmer 's  task. 


2.   LOGIC  SIMULATION  CONTROL 

The  Control  Unit  Logic  Simulator  System  consists  of  two 
major  parts:   the  CU  Card  Logic  Simulator  System  and  the  CU  Section 
Logic  Simulator  System.   The  purpose  of  the  CU  Card  Logic  Simulator 
System  is  to  assist  in  debugging  card  designs  and  to  calculate  the 
expected  responses  of  the  actual  logic  circuits  to  various  tests 
which  may  be  applied  to  them.   It  will  also  be  used  to  develop  card 
simulation  subroutines  for  inclusion  into  the  CU  Section  Logic 
Simulator.   Finally,  since  the  simulator  incorporates  a  capability 
for  modification  to  simulate  the  effect  of  failures  of  the  logical 
elements,  a  Diagnostic  Generator  System  will  be  built  using  the 
simulator  as  a  nucleus.   This  will  be  used  to  develop  input  patterns 
to  be  used  for  production  tests  and  off-line  diagnostics.   The  CU 
Section  Logic  Simulator  System  will  be  used  in  a  similar  manner, 
except  with  respect  to  an  entire  functional  section  (e.g.,  ADVAST, 
FINST,  etc.)  of  the  Control  Unit. 

The  basic  unit  of  a  simulation  is  a  test  step  or  simulation 
of  one  clock  interval  (50  ns  in  the  ILLIAC  IV),  which  consists  of 
actions  occurring  in  the  following  order: 

1)  adjust  the  input  values  and  storage  element  contents  in 
response  to  commands  from  the  simulation  input  tape; 

2)  simulate  the  action  of  the  combinational  logic  during 
the  interval; 


3)   record  the  output  values  and  next  storage  element 
states.   Three  aspects  of  the  simulation  can  be  controlled  at  each 
test  step:   inputs  storage  element  state  and  output  usage.   Inputs, 
storage  elements  and  outputs  are  all  denoted  by  signal  names  which 
are  described  in  chapter  h. 

2.1  Input  Control 

¥e  will  call  input  values  the  logical  values  of  the  signals 
present  on  the  input  pins  of  the  CU  card  connector.  They  are  derived 
from  two  sources: 

1)  data  provided  with  the  test  step  to  simulate  the  card 
with  given  input  connections  (a  mapping  of  input  data  to  input 
wires  is  presupposed,  through  a  predefined  symbol  table  for  each 
card) ; 

2)  a  subset  of  the  previous  outputs  from  the  card. 

Also  the  input  values  can  remain  unchanged  from  the  previous 
test  step. 

2.2  Storage  Element  State  Control 

Synchronous  storage  element  states  can  change  only  at  the 
beginning  of  a  test  step.   Their  values  can  be  derived  from  four 
sources : 

1)  they  can  remain  unchanged  from  their  previous  state; 

2)  they  can  be  cleared  (register  initialization); 

3)  they  can  be  preset  to  some  set  of  logical  values  given 
with  the  input  data; 


k)      they  can  assume  their  next  logical  state,  i.e.,  the 
enahling  gate  values  indicated  by  the  previous  test  step  are 
transferred  to  the  storage  elements.   The  transfer  option  of  {h)   will 
normally  "be  used  since  this  corresponds  to  the  actual  physical 
operation  of  the  circuits. 

2.3  Output  Usage  Control 

At  the  end  of  each  test  step,  the  simulator  provides  a  com- 
plete record  of  the  logical  values  of  all  the  signals  on  the  CU  card 
and  also  of  the  logical  values  of  the  input  to  the  storage  elements  on 
the  hoard.   These  are  the  states  that  the  storage  elements  will  assume 
at  the  next  clock  pulse  if  the  "transfer"  option  is  used  for  storage 
element  control. 

The  user  may  not  be  interested  in  all  this  information,  so 
three  options  are  given: 

-  no  printout  at  all; 

-  unconditional  printout  with  two  suboptions : 
simulation  results  only, 
actual  and  expected  results  along  with  indicator 

pointing  to  the  differences  between  them; 

-  printout  only  if  the  results  differ  from  those  expected. 
The  user  also  has  the  option  of  choosing  the  base  in  which 

the  results  are  to  be  given,  i.e.,  octal  or  binary. 

2.14-  Global  Control 

To  assist  the  user  in  the  generation  of  each  test  case,  some 
global  controls  are  provided;  namely  the  option  of  specifying  the 
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repetition  of  test  steps  or  groups  of  test  steps,  as  well  as  the 
simulation  initialization  and  termination. 

2.^  Other  Desirable  Facilities  in  the  Language 

Most  of  the  time,  several  signals  are  used  in  exactly  the 
same  way  in  the  tests.   In  order  to  make  writing  a  program  easier,  it 
is  desirable  to  allow  grouping  of  these  signals  together  and  to  refer 
to  all  of  them  by  means  of  one  identifier.   In  the  same  way,  it  is 
quicker  and  more  mnemonically  meaningful  to  write  an  identifier  rather 
than  a  bit  pattern  itself  when  associating  the  same  bit  patterns  with 
the  same  signals  several  times. 

Finally,  since  the  B5500  has  the  ability  to  perf02nn  boolean 
operations  on  full  data  words,  it  is  possible  to  associate  a  different 
test  case  with  each  bit  in  the  ^7  bit  data  word  and  simulate  up  to 
^7  different  cases  in  parallel.   It  is  then  interesting  to  have  an 
entity  called  a  case  dependent  digit  (abbreviated  as  CDD)  the  value 
of  which  varies  with  the  test  case  in  which  it  is  used.   These  CDD's 
then  may  be  used  in  data  patterns  which  will  have  configurations  that 
vary  with  the  test  cases. 

2.6  The  Necessity  for  a  New  Control  Language 

Most  simulation  input  languages  are  designed  to  control  the 
simulation  of  a  whole  machine,  or  at  least  an  entire  functional 
section  of  a  machine.   However,  in  order  to  verify  the  logical  design 
of  single  printed  circuit  cards  through  the  CU  Card  Logic  Simulator, 
we  must  have  a  different  type  of  language  to  control  the  simulation 
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of  arbitrary  logical  elements.   The  level  of  the  instructions  must  be 
lower  than  in  previous  simulation  languages  and,  for  maximal  simula- 
tor efficiency,  a  simple  way  to  specify  parallel  simulation  must  be 
implemented.  For  this  reason,  a  new  language  TESLA  (for  TESt 
LAnguage)  and  its  translator  have  been  designed  and  built. 


3.   THE  lESLA  LANGUAGE 

TESLA  is  more  an  assembly-like  language  than  a  procedure- 
oriented  language.   One  unusual  feature  is  the  provision  offered  for 
simultaneous  generation  and  control  of  many  simulations.   Statements 
of  the  language  pertain  to  two  categories:   declarations,  and  test 
step  commands.   Statements  are  written  in  free-field  format  separated 
by  semicolons.   A  complete  syntax  specification  of  TESLA  is  given  in 
Appendix  A.   Examples  of  TESLA  declarations  and  statements  given  in 
this  chapter  are  taken  from  the  complete  TESLA  program  which  appears 
in  Appendix  B. 

3.1  Declarations 

There  exist  four  different  types  of  declarations  in  TESLA, 
as  described  below.   The  simulation  case  limit  declaration  must  appear 
at  the  beginning  of  each  program,  right  after  the  first  word  which 
must  be  BEGIN. 

The  other  types  of  declarations  may  be  freely  intermingled 
with  executable  statements,  provided  that  all  quantities  are  declared 
before  they  are  used.   Redeclarations  are  permissible.   But  if  a 
declaration  A  uses  some  other  declared  quantity  B  in  its  definition, 
every  time  A  is  used  it  will  include  the  value  B  had  at  the  time  A 
was  declared,  regardless  of  later  modifications  or  redeclarations 
of  B. 
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3. 1.1  Simulation  Case  Limit  Declaxatlons 

This  is  a  declaration  of  the  range  of  simulation  test  case 
inputs  to  "be  generated  in  parallel.  Because  of  the  flag  hit  in  the 
B5500  48  bit  word,  this  range  may  not  be  greater  than  ^7. 

Example  of  a  case  limit  declaration: 

CASES  [1:32]; 

which  specifies  that  32  test  cases  will  be  generated  in  parallel 
through  the  simulation. 

3.1.2.   Group  Declarations 

These  allow  the  user  to  associate  a  single  identifier  with  a 
list  of  signals  (e.g.,  some  set  of  input  signals  from  the  connector), 
or  storage  elements,  for  notational  convenience.   Groups  must  be  typed 
either  SIGNAL  or  STORAGE.   Their  respective  interpretations  within  the 
TESLA  translator  are  quite  different. 

Any  legitimate  signal  name  may  be  used  in  the  signal  list 
associated  with  a  signal  group  assignment.   By  "legitimate  signal", 
is  meant  an  existing  signal  of  the  simulated  CU  board,  i.e.,  a  signal 
name  appearing  in  the  predefined  symbol  table  of  this  board.   In  such 
a  context,  the  use  of  the  signal  name  refers  to  the  logical  value 
held  by  that  signal  at  the  time  its  name  is  used  in  a  test  step. 

Only  storage  element  output  signal  names  may  be  used  in  the 
signal  list  associated  with  a  storage  group  assignment.   In  this  case, 
the  use  of  the  signal  name  refers  to  the  next  state  of  the  storage 
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element^  i.e.,  the  state  the  storage  element  vill  normally  assume  at 
the  next  clock  pulse. 

Example  of  a  group  declaration: 

SIGNAL  GROUP  IKLA   (ABT-12--G0,  ABT-28--GO); 

associates  the  identifier  INIA  to  the  group  of  two  signal  names 
ABT-12--G0  and  ABT-28--G0. 

A   list  of  group  declarations  of  the  same  type,  separated  by 
commas  and  terminated  by  a  semicolon,  may  be  made  after  the  reserved 
words 

SIGNAL  ^ 

>  GROUP  . 
STORAGE  I 

Group  declarations  may  be  nested  to  any  depth,  provided  the 
types  are  consistent  and  the  groups  used  inside  the  signal  list  have 
been  previously  declared.   Mult i- signal  identifiers  (see  paragraph 
4.1.1  for  the  definition  of  these  MSI's)  of  SIGNAL  type  are  treated 
and  built  exactly  like  groups.   The  first  time  such  an  MSI  is  met,  a 
group  is  constructed  in  the  group  array  (see  paragraph  4.1.4)  so  there 
is  no  need  to  declare  an  MSI  as  a  group;  it  is  declared  when  used. 
Hence  MSI's  can  be  freely  used  in  the  signal  list  of  any  group 
declarations  like  signal  identifiers  and  group  identifiers. 

3'1»3  Data  Declarations 

A  data  declaration  allows  the  association  of  single  identi- 
fiers with  bit  patterns  for  notational  convenience.   Bit  patterns  may 
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Toe  expressed  either  in  octal  or  in  "binary  form,  the  base  being 
indicated  in  front  of  the  opening  parenthesis  of  the  parenthesis  pair 
which  must  surround  the  bit  pattern.   If  the  base  specification  is 
empty,  the  bit  pattern  will  be  assumed  to  be  in  binary.   A  CDD  may  be 
used  in  the  bit  pattern,  provided  it  has  been  declared  previously. 

A  list  of  data  assignments  separated  by  commas  may  be  made 
after  the  reserved  word  DATA,  the  list  being  terminated  by  a  semi- 
colon, e.g.  : 

DATA  PAT2  =  2(0A1A0A1A), 

PAT2  =  8(OBlB2B3Bi+B5B6BTB); 

associates  the  octal  and  binary  patterns  to  PATl  and  PAT2, 
respectively. 

3.1.4  Digit  Declarations 

A  digit  declaration  is  used  to  declare  case  dependent  digits 
(CDD),  i.e.,  digits  whose  values  vary  with  the  test  case  in  which  they 
are  used.   A  CDD  may  be  declared  in  octal  or  binary,  with  the 
(optional)  base  appearing  in  front  of  the  opening  parenthesis  of  the 
pair  surrounding  the  digits  of  the  CDD.   The  default  option  for  the 
base  is  binary.   The  first  digit  (octal  or  binary)  of  the  digit  list 
is  associated  with  the  lower  limit  of  the  simulation  cases  declara- 
tion, the  next  digit  is  associated  with  the  next  test  case,  etc. 

If  octal  base  is  used,  each  octal  digit  is  associated  with 
only  one  test  case;  i.e.,  the  three  bits  represented  by  each  octal 
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digit  determine  three  "bits  in  one  test  case  rather  than  one  "bit  in 
each  of  three  different  test  cases. 

A  repeating  pattern  may  be  expressed  by  explicitly  stating 
one  repetition  and  following  this  "by  a  repetition  factor  which 
indicates  how  many  times  the  given  pattern  is  to  he  concatenated  with 
itself  to  provide  the  desired  case  dependent  pattern,  e.g.: 

DIGIT  A   =  2(01)*  16; 

is  a  32  hit  pattern  of  alternating  O's  and  I's. 

Restriction:   CDD's  must  be  denoted  by  single  letters. 
Again  a  list  of  digit  assignments  separated  by  commas  may  be  made 
after  the  reserved  word  DIGIT,  the  declaration  being  terminated  by  a 
semicolon. 

Note:  The  "="  signs  in  declarations  are  superfluous  and  may 
or  may  not  be  used  according  to  the  user's  feelings  about  program 
readability. 

3.2  Test  Step 

A   test  step  consists  of  a  step  label  followed  by  a  series 
of  input,  storage  element,  and/or  output  control  statements.   The 
separator  between  the  step  label  and  the  statements  is  a  colon,  and 
every  statement  is  terminated  by  a  semicolon. 

Default  options  exist  for  all  of  these  statements  so  that, 
if  some  type  of  control  statement  is  omitted  during  a  test  step,  the 
input  to  the  simulator  for  that  test  step  will  still  be  completely 
defined. 


Ik 

3«2.1  Input  Control  Statement 

These  control  statements  are  used  to  adjust  the  values  of 
simulation  input  variables  at  the  beginning  of  each  test  step.   By 
specifying  case  limits  these  commands  may  be  restricted  to  apply  only 
to  input  variables  of  specified  test  cases  among  those  being  generated 
in  parallel.   Case  limits  must  be  contained  within  the  declared  range 
of  simulation  cases. 

INSET  and  INCLR  cause  specified  inputs  to  be  set  to  a 
logical  "one"  and  cleared  to  a  logical  "zero"^  respectively.   The 
reserved  identifier  ALL  and  the  (default)  empty  word  both  cause  the 
specified  action  to  be  applied  to  all  input  variables. 

INPUT  causes  the  values  of  the  members  of  specified  signal 
groups  to  be  modified  to  conform  to  a  specified  data  pattern.   The 
first  member  of  the  signal  group  is  assigned  the  value  of  the  first 
bit  of  the  data  pattern,  the  second  member  takes  on  the  value  of  the 
second  bit,  etc.   Therefore  the  order  in  which  members  of  signal 
groups  and  data  patterns  are  stated  is  important.   Note  that  strings 
of  case  dependent  data  assignments  apply  to  the  last  encountered  pin 
group  designator.   If  the  specified  data  pattern  is  longer  than  the 
signal  group,  leading  leftmost  digits  will  be  ignored.   A  data  pattern 
which  is  shorter  than  the  signal  group  will  resiilt  in  an  error 
condition. 

INDUT  permits  input  signal  values  to  be  set  to  the  values  or 
the  complements  of  the  values  of  signals  calculated  during  the  previ- 
ous test  step.   Note  that  the  input  value  will  remain  constant 
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throughout  the  test  step,  irrespective  of  changes  in  the  fed-hack 
signal  value;  the  simulator  performs  the  equivalent  of  a  sample-and- 
hold  operation.   This  instruction  has  not  appeared  to  be  very  useful 
for  the  simulation  tests,  so  it  is  not  yet  implemented. 

Only  signal  names  which  correspond  to  input  connections  can 
he  meaningfully  used  in  an  input  control  statement  (except  as  members 
of  the  signal  group  specified  by  the  output  group  designator  in  an 
IiroUT  instruction) .   Hence  any  attempt  to  control  the  value  of  a 
non- input  signal  will  be  flagged  as  a  nonfatal  error  and  will  not 
generate  any  code.   Only  signal  group  designators  may  be  used  with  the 
IKTUT  command.   Instructions  are  followed  in  sequential  order  and  may 
be  used  to  modify  the  results  of  a  previous  instruction,  even  within 
the  same  test  step. 

If  any  input  signal  is  not  mentioned  (explicitly  or  implic- 
itly) by  membership  in  a  group  in  some  input  control  statement  for  a 
test  step,  then  the  logical  value  of  that  signal  is  unchanged  from 
the  value  held  at  the  preceding  test  step.   This  applies  also  to 
unmentioned  test  cases  if  input  control  statements  are  constrained  to 
apply  only  to  specified  test  cases.   All  inputs  are  initially  cleared 
to  a  logical  "zero"  at  the  start  of  a  simulation. 

The  following  are  examples  of  some  input  control  statements: 

INSET  IID.A; 

will  set  the  signals  ABT-12--G0  and  ABT-28--GO  of  group  INIA  in  all  32 
cases  of  simulation. 
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IISET  [l:l6]  IN3; 
applies  the  set  command  only  to  cases  1  through  l6  of  the  IN3  signals. 

INCLR  AGO- *^-- GO; 

resets  the  32  cases  of  the  signals  of  the  MSI  AGO--^-^--GO  (c.f. 

chapter  h   for  the  definition  of  MSI's). 

INPUT  IN3  2(0101010101010101); 

resets  (sets)  the  odd  numbered  (even  numbered)  signals  of  the  in3 
group. 

3.2.2  Storage  Element  Control  Statement 

There  are  three  TESLA  commands  to  control  the  storage 
elements.  FFX  causes  the  storage  elements  in  the  logic  under  simula- 
tion to  assume  their  next  logical  states  as  determined  by  the  inputs 
to  their  enabling  gates  calciilated  during  the  previous  test  step. 

FFOLD  causes  the  previous  states  of  the  storage  elements  to 
be  retained  for  the  new  test  step,  even  if  the  simulated  inputs  to. 
these  elements  call  for  a  change  in  state. 

FFIN  is  analogous  to  the  input  assignment  statement.   It 
causes  the  stated  storage  group  value  assignments  to  occur,  presetting 
the  specified  storage  elements  to  the  indicated  states. 

It  is  possible  to  use  case  limits  to  restrict  storage 
element  control  statements  to  apply  only  to  specified  test  cases. 
Unless  otherwise  specified  by  explicit  storage  control  statements,  the 
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transfer  command  FFX  is  assumed  to  apply  to  all  storage  elements.   It 
is  also  implicitly  assumed  that^  at  the  start  of  each  simulation,  all 
storage  elements  will  be  initially  cleared  to  the  "reset"  state  (i.e., 
they  will  show  a  logical  "zero"  as  their  \incomplemented  output). 
Examples  of  storage  element  control  statements  are: 

FFX; 

produces  a  transfer  of  all  the  storage  elements  on  the  simulated  card. 
It  is  usually  omitted  "because  of  the  default  option. 

FFOLD; 

prevents  a  transfer  of  the  storage  elements  which  retain  their  old 
states. 

FFIN  STO  PAT2; 

sets  the  elements  of  the  storage  group  STO  according  to  the  value  of 
the  hit  pattern  PAT2.    (Cf.  chapter  k   for  the  assignment  mechanism.) 

3»2»3  Output  Control  Statements 

These  statements  are  used  to  control  the  printing  of  simula- 
tion results  at  the  end  of  each  test  step.   All  the  printing  commands 
may  "be  constrained,  by  specifying  case  limits,  to  apply  to  only  a 
portion  of  the  test  results  that  are  being  generated  in  parallel. 

PRIKIT2  and  PRIM'S  will  cause  printing  of  the  logical 
values  of  the  members  of  the  specified  output  groups  in  binary  or 
octal  form,  respectively.   The  reserved  identifier  ALL  and  the  default 
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option  (empty  specifications)  will  cause  the  printing  of  all  output 
variables  in  alphalDetic  order.   Both  signal  and  storage  groups  may  be 
used  in  an  output  control  statement. 

PRAC2  and  PRAC8  (PRint  And  ^ompare)  cause  printing  in 
"binary  and  octal,  respectively,  not  only  of  the  simulation  results 
but  also  of  programmer  specified  expected  outputs.   If  differences 
exist  between  the  expected  and  the  actual  outputs  pointers  are  printed 
which  direct  the  observer's  attention  to  their  locations.   The 
requirements  for  data  pattern  alignment  and  ordering  are  the  same  as 
for  the  INHJT  command. 

PRire  and  PRIDB  (mint  If  Different)  are  similar  to  PRAC, 
but  printout  occurs  only  if  there  are  differences  between  the  expected 
and  actual  outputs.   If  the  simulation  output  is  as  expected,  no 
printout  occurs. 

All  desired  printout  must  be  called  for  explicitly.   The 
default  option  for  the  printout  command  is  no  printout  at  all. 

Examples : 

PRIKT2  INIA; 

will  print  the  bit  pattern  of  the  signals  of  group  INIA  in  binary. 

PRAC2  IN3  2(0101010101010101); 

will  print  in  octal  the  bit  pattern  of  the  signals  of  group  IN3  at  the 
instant  when  this  command  is  executed,  and  \inderneath  the  bit  pattern 
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specified  in  the  command  with  a  marker  pointing  to  the  cases  showing 
discrepancies . 

3.2.^  Simulation  Control  Commands 

These  commands  allow  easy  specification  of  the  repetition  of 
a  test  step;,  or  a  sequence  of  test  steps. 

The  sequence  repetition  specification  LOOP  will  cause  all 
test  steps  following  the  LOOP  command  up  to  and  including  the  step 
with  the  specified  lahel  to  be  repeated.   This  command  has  not  yet 
"been  implemented  in  the  translator. 

A  step  repetition  specification^  the  REPEAT  command^  allows 
the  execution  of  a  given  single  test  step  any  desired  number  of  times. 

The  default  option  for  these  two  simulation  controls  is  a 
specification  factor  of  one  (i.e.,  no  repetition). 

Example : 

REPEAT  3 
STEPIO :   ; 

will  cause  the  execution  of  the  whole  of  STEPIO  three  times  before 
continuing  with  execution  of  the  rest  of  the  program. 
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k.      THE   TESLA  TRANSLATOR 
^.1  Philosophy  of  the  Translator  Design 

^.1.1  Use  of  the  TVfS 

The  TESLA  Translator  was  written  with  the  help  of  the 
ILLIAC  rv  Translator  Writing  System  (TWS).   The  translator  requires 
only  one  pass  and  it  is  made  of  essentially  three  parts:   the 
scanner ;  the  parser  and  the  semantic  routines. 

The  parser  is  a  Floyd  Production  Language  interpretive 
parser  (Beals,  LaPrance^  Northcote  [3])  generated  by  the  TWS  system 
from  the  syntax  specification  listed  in  Appendix  A. 

The  standard  TWS  scanner  (Baker  [h])   had  to  be  modified 
somevhat  to  meet  particular  TESLA  requirements.   A  table  of  identi- 
fiers denoting  the  names  of  each  of  the  signals  in  a  board  is  created 
during  the  simulator  generation  process.   These  identifiers  are  ten 
characters  long  and  they  usually  contain  the  non- alphanumeric  char- 
acter "-"^  although  some  do  not.   A  typical  example  of  a  signal  name 
is  ABT-13--G0.   Because  of  the  prescribed  signal-naming  rules, 
related  signals  (e.g.,  the  6k   bits  of  a  register)  have  quite  similar 
names,  differing  in  only  one  or  two  characters.   It  is  interesting 
then  to  be  able  to  refer  to  all  the  signals  of  such  a  group  by  a  new 
type  of  identifier,  called  a  Multi  Signal  Identifier  (or  MSl).   These 
MSI's  contain  "^"  's  as  "don't  care"  characters;  that  is,  in  place  of 
characters  which  may  vary  among  the  signals  of  the  group,  e.g.: 
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denotes  the  group  of  all  signals  denoted  "by  identifiers  having  any 
character  in  positions  6  and  7  of  the  identifier  name,  and  the 
specified  characters  A,   B,  T^  -,   etc.  in  the  other  positions. 

Because  signal  identifiers  and  MSI's  are  frequently  syntac- 
tically permitted  to  occur  in  the  same  places  as  ordinary  Identifiers 
(group  designators)^  they  must  be  scanned  as  special  "but  legal 
identifiers  in  TESLA.   When  TESLA  was  applied  later  to  PE  card 
simulations^  it  was  discovered  that  EE  signal  names  sometimes  used 
"f"  instead  of  "-",  thus  requiring  another  small  modification. 

The  standard  TWS  scanner  recognizes  identifiers  and  numbers 
without  the  necessity  for  syntactic  specification^  converting  the 
individual  characters  into  a  single  symbol  directly  in  the  scanner. 

On  the  other  hand,  CDD's  and  bit  patterns  are  specified  by 
strings  of  numeric  and  possibly  alphabetic  (in  the  case  of  bit 
patterns)  characters,  which  must  be  scanned  as  strings  and  not  as 
numbers.   This  is  achieved  by  switching  the  scan  mode  to  character 
mode  by  executing  a  semantic  action  right  before  the  recognition  of 
one  of  those  bit  patterns,  and  restoring  it  to  normal  identifier  scan 
mode  immediately  after.'   Hence  the  scanner  tests  the  value  of  the 
variable  SCANMODE  when  a  digit  is  scanned.   Other  numbers  are  scanned 

and  evaluated  as  standard  B5500  numbers.   Since  numeric  quantities  in 

12 
TESLA  are  guaranteed  to  be  less  than  kO^G   =2  ,  the  scanner  puts  the 

value  of  the  number  directly  into  the  12  bit  field  MSTACKt  PIMSTACK]  • 

[l8:12],  instead  of  in  a  location  of  BIGTAB  pointed  to  by 
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MSTACK[PrMSTACK]  •  [l8:12].   This  avoids  one  level  of  indexing  in  the 
case  of  numbers. 

The  actual  translation  is  performed  "by  the  semantic  actions 
which  are  called  during  the  parsing. 

^.1.2  General  Organization  of  the  Simulator-Translator  System 

The  TESLA  Translator  belongs  to  the  Data  Preparation  group 
of  programs  of  the  Simulator  System.   This  subsystem  creates  two  disk 
files  for  each  simulation. 

1)  The  first  file  contains  the  input  to  the  simulator 
itself.   One  variable  length  record  (covering  a  few  logical  records  of 
the  file)  per  test  step  specifies  the  input  control^  all  new  input 
values  (i.e.,  the  symbols  of  the  simulation  input  (A)  array  which  have 
been  modified  in  the  test  step),  the  storage  element  control,  and  any 
preset  values  for  the  storage  element  states. 

2)  A   second  file,  also  with  one  variable  length  record  per 
test  step,  contains  the  output  control  and  the  output  signal  values  at 
the  end  of  the  test  step  together  with  the  expected  outputs,  if  any. 
This  file  is  not  used  by  the  simulator  itself,  but  by  the  results 
display  program  for  comparison  against  the  simulation  results  in 
output  editing  and  printing.   It  contains  a  record  of  all  the  values 
of  every  signal  (every  element  of  the  arrays)  at  the  end  of  each 
simulation  step.   The  general  organization  of  the  system  is  shown  in 
Figure  2. 
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^.1.3  Different  Types  of  Signals  and  the  Signal  Arrays 

The  simulator  input  is  the  object  code  for  the  compiler,  so 
a  general  idea  of  what  is  necessary  for  the  simulator  input  is 
required. 

Because  of  addressing  limitations  within  the  simulator 
itself,  signal  values  are  stored  in  arrays.   Each  signal  (there  are 
from  several  hundred  to  several  thousand  in  a  typical  simulation)  has 
assigned  to  it  a  unique  subscript  in  some  array.   The  different 
signals  in  the  simulator  are  divided  into  three  categories  according 
to  their  function,  use  and  position  with  respect  to  storage  elements. 
This  categorization  is  then  used  to  determine  to  which  array  the 
signal  is  assigned.   Within  an  array  (signal  category),  signals  are 
arranged  alphabetically.   If  any  of  the  connections  from  a  particular 
signal  is  attached  to  a  connector  pin,  then  it  is  a  source  (i.e., 
input)  or  load  (i.e.,  output)  signal  from  the  board.  Figure  3  shows 
the  different  types  of  signals. 

1)  Input  signals,  like  ALl,  AL2,  AL3,  Plh,   XRl  in  Figure  3, 
are  mapped  in  the  simulator  system  into  elements  of  an  array  called 
the  A  array. 

2)  Output  signals,  like  BKZ,  BKY,  BKX,  are  mapped  into  the 
elements  of  another  array,  B. 

3)  Intermediate  signals,  like  ARO,  are  mapped  into  elements 
of  the  C  array.   Another  array,  D,  is  used  for  overflow  if  there  are 
more  than  512  intermediate  signals.   A  second  array  is  used,  rather 
than  Increasing  the  dimension  of  C,  for  efficiency  reasons.   Two  arrays 
are  sufficient  because  there  will  never  be  more  than  1023  internal 
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signals.   These  two  arrays  C  and  D  have  no  particular  function  in  the 
compiler. 

Hence  there  exists  a  one  to  one  correspondence  between  the 
signals  and  the  elements  of  the  A,  B^  C,  and  D  arrays,  as  defined  in 
a  symhol  table  kept  in  the  input  file  named  SYMBOL.   This  file  is 
created  for  each  board  by  a  small  program  TESLA/MERGE  out  of  the 
files  (board  name)/SIGNAL  and  (board  name)/STORAGE  which  define, 
respectively,  all  the  signals  and  all  the  storage  elements. 

The  array  locations  corresponding  to  signal  names  have  a 
symbolic  representation  of  1^  bits : 


5  bits 

9  bits 

T  t 

code  for  the        subscript  value 
array  name         (range  0-511) 


This  representation  is  referred  to  as  the  SYMBOL  of  the  signal  name. 
Two  bits  would  be  sufficient  to  code  the  four  currently  used  array 
names,  but  five  bits  are  provided  for  expansion.   At  present 

A  is  coded  by  00000 

B  is  coded  by  00001 

C  is  coded  by  00010 

D  is  coded  by  00011 

Besides  these  four  arrays  another  one,  the  Q  array,  contains 
a  copy  of  the  values  of  the  storage  elements.   No  special  code  for  this 
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array  name  is  needed  because  its  elements  are  used  in  a  distinct 
context  where  no  ambiguity  is  possible. 

4.1.^  Basic  Decisions  about  the  Compiler  Design 

A   detailed  examination  of  the  object  code,  command  by 
command,,  is  given  in  the  next  paragraph;  but  a  few  basic  decisions 
about  the  compiler  must  be  exposed  first. 

It  is  desired  to  optimize  the  speed  and  efficiency  of  the 
simulator  to  the  greatest  possible  degree.   If  any  tasks  could  be 
performed  within  the  compiler  which  could  result  in  simpler  and  faster 
running  input  to  the  simulator ,  then  they  should  be  included  in  the 
translator  design.   Thus,  for  example ,  only  one  object  command  of  a 
given  type  is  put  out  at  the  end  of  each  test  step,  rather  than  one 
object  command  per  source  command.   To  realize  this  a  copy  of  the 
A   array  (or  array  of  the  input  symbols)  and  the  Q  array  (or  array  of 
the  storage  elements)  is  kept  inside  the  compiler.   Even  if  a  source 
command  only  affects  a  small  number  of  the  total  range  of  test  cases 
for  some  set  of  variables,  it  is  frequently  possible  to  put  out  a 
more  efficient  object  command  affecting  all  test  cases.   Recalling 
the  simulation  rule  that  an  input  remains  "unchanged  from  its  previous 
value  unless  specifically  modified,  it  can  be  seen  that  if  a  copy  of 
the  simulator's  input  array  is  kept  within  the  translator  itself,  it 
is  almost  always  possible  to  fill  in  the  values  for  the  remaining  test 
cases.   Only  when  the  INOUT  command  has  been  used,  does  this  technique 
break  down,  since  there  is  no  longer  any  certainty  of  the  values  in 
the  simulator's  input  array  for  signals  which  have  been  affected  by 
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this  command.   (The  values  which  will  be  assigned  to  the  members  of 
the  input  group  are  known  only  at  simulation  tinie.)  But  if  these 
signals  are  later  specifically  set  to  some  predetermined  value  by  one 
of  the  other  input  source  commands  values  are  again  known.   Similar 
reasoning  applies  to  the  states  of  the  storage  elements,  except  that 
their  values  are  generally  quite  uncertain,  unless  they  have  been 
preset  to  a  certain  state  by  some  source  command. 

Thus  an  uncertainty  mask  and  two  flags  are  associated  with 
each  element  of  the  two  (A   and  Q)  arrays  (c.f.  Figure  4).   The 
uncertainty  mask  is  used  in  relation  with  case  dependent  commands: 
a  bit  1  in  a  given  position  of  the  ^7  ti't  uncertainty  mask  signals 
that  the  Value  of  the  corresponding  bit  of  the  corresponding  element 
of  the  A   (or  Q)  array  cannot  be  predetermined.   As  soon  as  one  bit  of 
the  uncertainty  mask  is  a  "1",  the  uncertainty  flag  is  turned  on,  and 
when  all  bits  of  the  mask  are  reset  the  uncertainty  flag  is  turned 
off.   (The  xmcertainty  flag  can  be  simply  viewed  as  the  inclusive 
OR  of  the  bits  of  the  uncertainty  mask.)  Hence  the  uncertainty  flag 
is  the  indicator  that  the  uncertainty  mask  should  be  used  in  the  • 
evaluation  of  the  array  elements. 

The  other  flag  is  the  activity  flag;  it  is  turned  on  each 
time  the  configuration  of  the  corresponding  A   (or  Q)  array  element  is 
modified  during  a  step. 

This  setup  requires  some  bookkeeping  in  the  compiler  but 
allows  the  emission  of  condensed  object  code:  one  command  of  each 
type  only  per  test  step.   A  scan  through  the  flag  array  is  sufficient 
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to  decide  if  an  array  element  has  been  modified  in  the  test  step  and 
which  object  code  command  produces  this  modification.   The  system  can 
then  string  together,  into  a  single  command,  all  the  A  array  elements 
affected  by  a  particular  type  of  command. 

Another  basic  point  of  the  compiler  philosophy  has  been 
that  all  outputs,  i.e.,  the  simulator  input  and  the  print  control 
input,  will  always  consist  of  pairs  of  words.   This  decision  will  lead 
to  the  waste  of  a  few  words,  but  not  many  because  most  of  the  time  the 
format  of  the  command  covers  an  even  number  of  words.   The  general 
format  for  simulator  input  data  is  shown  in  Figure  5» 
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pair  of  words  always 
present 

additional  pair  of  words 
necessary  for  some 
instructions 


Figure  5'   General  Format  for  Simulator  Input  Data 

TTie  compiler  builds  and  maintains  other  arrays  among  which 
the  three  most  important  are : 


the  group  array  named  GA 
the  data  array  named  DA 
the  CDD  array  or  CDDAERAY 
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Other  arrays  such  as 

the  hit  pattern  array  BP 
the  signal  list  array  SL 
the  digit  stack  DS 

are  temporary^  hut  are  important  in  the  construction  of  the  permanent 
ones. 

The  group  array  GA  is  an  array  containing  all  the  elements 
of  all  the  groups.   Each  group  is  a  seq^uence  of  words  of  GA,  each 
word  containing^  right- justified^  the  SYMBOL  of  a  signal  of  the  group 
(i.e.,  the  1^  bit  code),  with  a  heading  word  containing  the  length  of 
the  group  (i.e.,  the  number  of  elements  in  the  group)  in  a  1^  bit 
field  and  an  indicator  (called  SSI  for  short)  of  the  type  of  the 
group,  either  signal  or  storage.   This  flag  SSI  is  bit  1  of  the 
heading  word.   (See  Figure  6.) 


< 1  word ■> 


SSI 


3^   ^7 


lengtJn 


sequence  of  SYMBOL'S  in  the  order 
of  the  signal  names  given  when  the 
group  was  declared. 


Figure  6.   The  Storage  of  a  Group  in  GA 
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A   pointer  GAPTR  always  points  to  the  last  meaningful  entry  in  the 
group  array  GA. 

As  soon  as  a  group  is  available  in  GA,  the  semantic  field 
of  the  entry  in  BIGTAB  corresponding  to  the  group  identifier  is  used 
as  a  pointer  to  the  heading  vord  of  the  group  built  in  GA.   Hence 
this  group  can  be  accessed  again^  if  needed,  by  simple  indexing. 

When  a  group  declaration  is  recognized,  the  groups  are 
transferred  into  the  group  array,  once  they  have  been  built  in  the 
signal  list  array  SL.   The  first  used  word  of  the  SL  array  always  has 
the  index  1,  so  that  the  signal  list  pointer  (SLECR)  which  always 
points  to  the  last  meaningful  information  in  SL,  has  as  its  value 
the  number  of  elements  in  the  group  under  construction.   This  value 
is  used  in  making  the  header  just  before  the  transfer  of  the  group 
elements  in  GA. 

MSI's  of  SIGNAL  type  are  retrieved  exactly  like  groups 
except  that  their  first  use  in  any  command  suffices  as  a  declaration; 
no  special  declaration  is  needed. 

The  Data  Array  (DA)  is  similar  to  the  group  array.   It  is 
constructed  according  to  the  same  principles,  using  the  bit  pattern 
array  (BP)  as  a  temporary  array  in  which  to  build  the  bit  patterns 
before  transferring  them  to  DA,  along  with  a  header  containing  the 
length  of  the  bit  pattern.   Each  "bit"  of  the  bit  pattern  is  stored 
in  one  full  word  of  the  DA,  since  that  bit  has  some  value  for  each 
test  case,  and  must  be  stored  as  such.   CDD's  may  be  used  instead 


33 


of  bits,  provided  they  have  been  previously  declared;  their  "bits  are 
similarly  stored  across  the  word  of  DA,  e.g., 

DIGIT  A  =  (01)^16; 
DATA  PAT  =  2(10A0); 

will  generate  in  DA  the  hit  patterns  written  from  right  to  left  as 
shown  in  Figure  7* 


bit' 


<- 



1  word -> 

01     25                        34         ki 

PAT 
i 

lvalue  of  4 

11 11111 

1 

00 00000 

0 

10 01010 

A 

0  0__..  _.___..   ._.    .____0_0  0_  0  0 

0 

Figure  7«   Example  of  a  Data  Pattern  in  DA 


The  first  used  word  of  the  BP  array  always  has  the  index  1  and  a 
pointer  BPPTR,  always  points  to  the  last  meaningful  information  so 
that  when  the  list  is  ready  to  be  transferred  into  DA,  BPPTR  contains 
the  length  of  the  bit  pattern.  When  the  bit  pattern  is  declared  in 
octal  instead  of  binary,  it  is  assigned  the  binary  representation  of 
the  octal  number. 

The  semantic  field  of  the  BIGTAB  entry  corresponding  to  the 
data  designator  contains  the  pointer  to  the  header  word  of  the  data 
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designator  specification  in  DA.   In  order  to  differentiate  in  BIGTAB 
between  the  pointers  to  the  arrays  GA  and  DA,  the  first  bit  of  the 
semantic  field  is  used  as  a  flag.   We  call  it  DDGDF  for  Data 
Designator/ Group  Designator  Flag. 

DDGDF  =  0  (or  FALSE)  means  pointer  to  GA. 
DDGDF  =  1  (or  TRUE)  means  pointer  to  DA. 

The  CDD's  are  also  built  into  an  array  called  digit  stack 
(DS)  and  are  stored  in  an  array  called  CDDARRAY,  at  the  time  of  their 
declaration,  so  that  they  may  be  used  later  on. 

They  are  mapped  into  a  machine  word  starting  from  the  right 
and  moving  towards  the  left,  e.g., 


bit  pattern  00101... 
is  mapped  into 


(Ol)"^l6  is  mapped  into 


bit 


bit- 


01 


.    .    .    .    1  0   1  0  C 

■012 

1^3  t^5T^T 
kk    k6 

1 

10.... 

...      1  0  1  0  1  c 

l6t 
17 
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To  form  the  pattern,  use  is  made  of  the  digit  stack  DS  which  is,  in 
fact,  a  list  where  the  sequence  of  bits  is  placed  one  by  one  as  they 
are  recognized.   An  example  is  given  in  Figure  8. 

The  bits  are  then  put,  by  shifting  and  concatenation,  into 
the  ODD  pattern. 


35 


bit— »01 


-DSPTR 


Figure  8.   Representation  of  (Ol)*l6  in  DS 

A   CDD  may  be  specified  in  octal  instead  of  binary.   Then 
each  octal  digit  is  associated  with  only  one  test  case  (i.e.,  the 
three  bits  represented  by  each  octal  digit  determine  three  bits  in  one 
test  case,  rather  than  one  bit  in  each  of  three  test  cases).   Hence 
the  digit  pattern  then  obtained  occupies  three  words.   In  fact,  an 
octal  CDD  generates  three  binary  CDD's.  Figures  9  and  10  show  the 
different  stages  in  the  construction  of  the  octal  CDD  8(o6)*l6. 
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Figure  10.   The  Three  "Bits" 
of  the  Octal  CDD 


Figure  9« 


Representation  of 
8(06)*l6  in  DS 
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As  a  CDD  is  alvays  denoted  by  a  single  letter,  there  is  a 
maximum  of  26  such  digit  patterns.   In  order  to  access  the  CDD's  in 
the  CDDARRAY  "by  using  as  an  index  the  numeric  code  of  the  letter 
representing  the  CDD,  the  CDDARRAY  has  a  particular  format.   There  are 
12  special  characters  in  the  middle  of  the  alphabet  (same  as  Burroughs 
coding).   Hence  the  CDDARRAY  will  have  26  f  12  =  38  rows,  numbered 


38 

rows 


base 

Bitl 

Bit2 

Bits 

« — 1  word-» 

< — 1  word-* 

< — 1  word-* 

<— 1  word — > 

Figure  11.  Format  of  the  CDDARRAY 


from  0  to  37'   The  numeric  code  for  a  letter  must  have  I7  subtracted 
from  it  (17  is  the  numeric  value  of  the  code  for  the  letter  A)  before 
computing  the  index. 

This  fixed  format  for  the  CDDARRAY  leads  to  some  wasted 
memory  in  the  case  of  binary  case  dependent  digit,  but  it  allows  an 
easy  implementation  for  dynamic  redeclarations  in  a  program;  there  is 
no  problem  when  switching  from  binary  to  octal  for  a  given  CDD. 
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k.2     Object  Code  Commands:  Their  Format 

and  Semantic  Meaning  for  the  Simulator 

4.2.1  Simulator  Input  Commands 

The  object  code  input  commands  are  divided  into  three 
different  groups. 

4.2.1.1  Initialization  Commands 

These  commands  assign  data  patterns  to  elements  of  the  A 
array.   According  to  the  circumstances  and  types  of  assignment,  and 
uncertainty  or  not  of  the  "bit  values,  one  of  the  four  following 
commands  is  used.   The  command  verhs  are,  in  fact,  replaced  hy  coded 
values  which  can  he  found  in  Appendix  C 

l)   INI  command:  The  format  of  the  TNI   command  is  shown  in 
Figure  12,  where  n  is  the  number  of  assignments  to  be  performed  while 


Datal 


//////////// 


SIMB2 


Data2 


Figure  12.   Format  of  an  im.  Command  Block 
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carrying  out  the  INI  command^  i.e.,  n  is  the  niomber  of  (following) 
pairs  of  words  in  the  scope  of  the  INI  verb. 

The  action  taken  by  the  simiilator  on  the  block  in  Figure  12 
will  be  (expressed  in  a  pseudo-ALGOL  form) 

A[SyMBl]  ^  Datal; 
A[SYMB2]  4-  Data2; 

Note  that  the  SYMBOL'S  present  here  (SYMBl,  SYMB2,  etc.)  are  in  fact 
only  subscript  values  since  the  signals  being  set  are  always  elements 
of  the  A  array;,  the  array  code  for  which  is  00000. 

Such  an  INI  command  block  is  easy  to  output  at  the  end  of 
each  test  step.   The  translator  must  merely  scan  through  the  flag 
array  AF  to  detect  the  activity  flags  set.   If  no  uncertainties  are 
present,  then  n  is  simply  the  number  of  those  flags  set.   The  SYMBOL'S 
are  the  subscripts  of  the  elements  whose  flags  are  detected  and  the 
data  are  the  patterns  to  which  the  A[ index] 's  must  be  set. 

2)   IN2  command:  As  soon  as  one  bit  of  the  uncertainty  mask 
Is  on,  the  INI  verb  must  be  replaced  by  the  IN2  verb,  because  an 
uncertainty  mask  must  also  be  put  out  along  with  the  subscript  and  the 
data.  Figure  13  shows  the  format  of  an  IN2  command  block  where  n  is 
the  number  of  assignments  to  be  performed  in  accordance  with  the  IN2 
command.   The  action  performed  at  simulation  will  be: 

A[SYMB1]  ♦.  (A[SYMB1]  ANL  MASK)  OR  (DATAl  AND  NOT  MASK); 

A- 

I 

current  value  of  A[SyMBl]  given  by  the  simulator. 
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Note:   The  expression  (DATAl  AND  NOT  MASK)  can  be  evaluated 
inside  the  compiler  "because  DATAl  and  MASK  are  known  at  compile  time. 
So^  in  fact^  the  DATAl  put  out  by  the  compiler  will  be  the  result  of 
the  operation 

(original)  DATAl  AND  NOT  MASK 

and  the  simulator  will^  in  fact^  simply  perform: 

A[SmBl]  4-   (A[SmBl]  AND  MASK)  OR  DATAl. 

In  general  the  object  code  consists  of  a  combination  of  INI 
and  IN2  commands.   The  uncertainty  is  created  by  the  use  of  the  TESLA 
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specification  of 
one  assignment 


Figure  13 .  Format  of  an  IN2  Command  Block 
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source  command  lEOUT.   As  certainty  about  the  value  of  bits  of  the 
A   array  elements  is  regained;  the  corresponding  bits  of  the  uncertain- 
ty mask  are  reset.  When  the  last  one  is  turned  off ^  the  uncertainty 
flag  bit  is  also  reset.   The  IN2  command  must  be  used  until  complete 
certainty  is  regained  about  the  A   array  elements  affected  by  an  INOUT 
command. 

3)   IN3  command:  IN3  is  the  object  order  corresponding  to 
the  INOUT  source  command.   The  IN3  block  format  is  shown  in  Figure  ik, 
where  n  is  still  the  number  of  assignments  to  perform^  i.e.,  the 
length  of  the  list  in  the  scope  of  the  IN3  command. 

IKV  stands  for  inversion,  i.e.,  the  logical  (or  one's) 
complement.   The  whole  field  IKV  (i.e.,  eight  bits)  takes  the  values 

0  for  no  complement 

1  for  one's  complement. 


v//////////////Z^, 


Figure  l4.   Format  of  an  IN3  Command  Block 
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The  SYMBx's  represent  elements  of  the  A   array  only,  so  their 
values  are  only  the  sulDScripts  of  these  elements.   However  the 
SIMBxP's  may  represent  elements  of  any  array,  so  they  include  the 
code  for  an  array  name  in  the  five  high  order  bits.   The  assignment 
performed  by  the  simulator  is  then 

A[SmBx]  ♦-  n;  IW  then  not  signal (SYMBxP)  else  signal (SYMBxP); 

■where  SIGNAL (SYMBxP)  is  a  boolean  typed  procedure  giving  the  current 
value  of  the  variable  designated  by  SIMBxP. 

Since  we  cannot  a  priori  determine  the  value  of  SIGNAL,  this 
command  makes  the  compiler  lose  certainty  about  the  values  of  the 
corresponding  A  array  elements.   Therefore  the  bits  of  the  uncertainty 
mask  corresponding  to  the  bits  of  the  A  array  elements  affected  by  the 
INDUT  (i.e.,  IN3)  command  are  set  on. 

h)     IN4  command:  IN4  replaces  the  IN3  command  in  the  case 
of  an  INOUT  with  case  limits,  e.g.,  INOUT  GRPl  [l:l6]  GRP2j  .   It  is 
not  possible  in  this  case  to  compute,  at  compile  time,  the  value  of 
the  A  element  using  the  partial  mask  as  in  the  INI  case,  because  the 
values  of  the  GRP2  elements  are  unknown  at  compile  time.   Conse- 
quently, the  mask  must  be  put  out  along  with  the  two  SYMBOL'S,  and  the 
assignment  will  be  performed  at  simulation  time  when  the  values  of 
GRP2  are  shown. 

The  IN4  block  format  is  shown  in  Figure  I5,  where  n  is  the 
length  of  the  list  of  pairs  of  words  in  the  scope  of  the  IN4  verb, 
i.e.,  the  number  of  assignments  to  be  performed. 
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Figure  15 .  Format  of  an  T^   Command  Block 


The  assignment  performed  at  simulation  time  is: 

ACSYMBl]  «-  ((EF  INV  THEH  WOT  SIGNAL  (SYMBIP)  ELSE 
SIGNAL (syKBlP))  AND  NOT  MASK)  OR  (A[SYMB1]  AND  MASK); 

where  SIGNAL  again  gives  the  contents  of  the  array  element  to  be  used 
as  input  in  the  assignment. 

4.2.1.2  Register  Control  Commands 

There  are  three  verbs  in  the  object  language  to  control  the 
storage  elements  or  registers.   They  are  related  to  the  TESLA  commands 
FFX,  FFOLD  and  FFIN^  but  there  is  no  one-to-one  correspondence.  FFl 
takes  care  of  FFX  and  FFOLD,  and  the  object  commands  FF2  and  FF3  are 
needed  to  take  care  of  FFIN  depending  on  the  situation  in  which  that 
verb  is  used. 

l)  FFl  command:  The  FFX  and  FFOLD  commands  apply  to  all 
the  storage  elements  on  the  board.   They  are  both  translated  into  the 
FFl  command,  the  distinction  between  the  two  being  made  by  means  of 
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a  flag,  vhich  is  the  last  bit  of  the  Ql  field  of  the  FFl  command. 
The  Ql  field  is  not  required  for  any  other  use;  no  record  of  the  scope 
of  the  command  need  he  kept  as  in  the  case  of  IKL   "because ,  by 
definition,  it  applies  to  all  flip-flops. 

The  format  of  this  FFl  command  is  shown  in  Figure  17-   The 
rightmost  hit  of  the  Ql  field  is  used  for  the  FFOLD  flag,  which  is  on 
if  there  is  any  retention  from  the  old  state  of  the  storage  elements, 
considering  all  the  test  cases.   The  MASK  indicates  in  which  cases 
there  must  he  retention  of  the  old  state. 
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<y////////A  FFiF 


^7 


FFOLD  MASK 


-FFOLD  flag 


Figure  I7.  Format  of  an  FFl  Command 

If  there  are  K  f  1  elements  in  the  Q  array  of  the  storage 
elements,  the  execution  of  the  FFl  command  hy  the  simulator  will 
realize : 

EF  FOLDFLAG 

THEN  FOR  I  :=  0  STEP  1  UNTIL  K  DO 

Q[I]  :=  (Q[I]  AI©  MASK)  OR  (QQ[I]  AND  NOT  MASK) 
ELSE  FOR  I  :=  0  STEP  1  UNTIL  K  DO 


Q[I]  :=  QQ[I]; 


^5 


vhere  QQ[I]  denotes  the  next  state  of  the  I-th  flip-flop  at  the  end 
of  the  test  step. 

Note :  The  FFl  cotnmand  is  alvays  issued  at  the  end  of  each 
step.   Only  one  is  issued  per  step  and  it  must  he  the  first  register 
control  command  since  it  modifies  the  state  of  all  memory  elements. 
If  no  storage  element  control  statement  is  explicitly  stated  in  a 
step^  the  default  option  is  an  EFl  with  no  old  state  retention,  i.e., 
the  FFOLDFLAG  is  reset. 

2)  FF2  and  FF3  commands:  These  commands  are  used  as  a 
translation  of  the  TESLA  verb  FFIN.   Several  FF2's  and  FF3*s  may  he 
put  out  in  a  step.   They  are  used  to  preset  the  configuration  of  some 
flip-flops. 

FF2  is  generated  in  the  case  of  a  FFIN  statement  with  no 
case  limits j  all  the  test  cases  of  the  signal  are  set  according  to  the 
value  of  the  pattern.  The  format  of  an  FF2  block  is  shown  in 
Figure  l8,  where  n  is  the  length  of  the  list,  i.e.,  the  number  of 
storage  element  assignments  of  the  FF2  type; 

SI  and  S2  are  subscripts  of  elements  of  the  Q  array.   The 
assignment  performed  by  the  simulator  is 

Q[S1]  ^  Patter nl; 
Q[S2]  *-  Pattern2; 


FF3  is  generated  in  the  case  of  a  FFIN  statement  including 
case  limits;  only  some  test  cases  are  assigned  a  value,  and  a  mask  is 
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Figure  l8.   Format  of  an  FF2  Command  Block 

output  ac  necessary  information  to  perform  the  assignment.   This  mask 
is  a  retention  mask  as  in  the  case  of  the  FFOLD  or  IN2  commands.   An 
FF3  command  block  is  pictured  in  Figure  \S ,   where  n  is  the  length  of 
the  list,  i.e.,  the  number  of  storage  element  assignments  of  the  FF3 
type. 
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Figure  19*  Format  of  an  FF3  Command  Block 
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The  assignment  performed  by  the  simulator  in  this  case  is 

q[Sl]  ^   (Q[S1]  MD   MASKl)  OR  PATTEMIM 

where  PATTERNIK  is  the  result  of  the  operation 

PATTEEm  MD   MASKl 

performed  inside  the  compiler. 

^.2.1.3  Miscellaneous  Commands 

In  TESLA^  all  the  different-  types  of  commands  may  come  in 
any  order.   In  the  source  language^  the  end  of  a  test  step  is  marked 
"by  the  beginning  of  a  new  step,  i.e.,  "by  the  next  step  label.   In  the 
object  code,  the  end  of  a  test  step  has  to  be  indicated  by  a  special 
command,  End  of  IICPUT  (EOl).   It  indicates  that  all  inputs  for  a 
particular  step  have  occurred;  it  is  time  to  start  simulation.   The 
format  of  this  command  is  shown  in  Figure  20. 
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Figure  20.   Format  of  an  EOI  Command  Block 
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The  label  of  the  just-completed  step  is  attached  to  the  EOI  command. 
If  thic  label  is  an  identifier  longer  than  30  characters,  it  is 
truncated  after  the  ^Oth,    i.e.,    the  maximum  number  of  words  allowed 
to  3tore  the  step  label  with  an  BOX  command  is  five.   The  step  label 
is  issued  as  it  appears  in  BIGTAB:   i.e.,  six  characters  per  word  with 
two  leading  zeros  and  the  last  word  being  completed  with  blanks,  if 
necessary.   If  the  second  word  of  the  last  pair  is  not  used  to  store 
characters  of  the  label,  it  is  filled  with  zeros  by  the  compiler.   The 
number  of  characters  in  the  identifier  put  out  in  this  block  is  stored 
in  the  l4-bit  Ql  field  of  the  EOI  command  word. 

The  end  of  a  TESLA  program  is  marked  by  an  END.  in  the 
source  code  to  signal  the  end  of  simulation  to  the  simiilator  and  the 
imminent  end  of  the  file,  permitting  an  orderly  shutdown  of  the 
simulator  itself.   This  is  the  EOF  command;  its  format  is  shown  in 
Figure  21.   It  is  issued  by  the  compiler  after  processing  the  last 
card  of  the  simulation  program. 


0 

26 

3^          47 

^///////, 

EOF 

V/A 

'/////////////A 

Figure  21.  Format  of  an  EOF  Command 

4.2.2  Print  Control  Commands 

These  commands  appear  in  the  printer  control  file  and  not  in 
the  simulator  input  file.   They  are  used  to  govern  the  printing  of  the 
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results  of  the  simulation  through  the  result  display  program.  When 
the  simulation  results  are  displayed  (in  addition  to  the  output 
information  iteslf )  the  step  lahel^  the  case  number  and  the  name  of 
the  group  associated  with  the  output  are  also  printed.  A   line  of 
output  corresponding  to  a  group  is  a  pattern  of  hits;  one  bit  for 
each  variable  in  the  group^  in  each  particular  test  case,  e.g. : 


<step  label> 

CASE  #1 

GRPl 

OUTGRP 

ALR 

CASE  #2 

GRPl 

OUTGRP 

ALR 

CASE  #3 


<sequence  of  bits> 
<sequence  of  bits> 
<sequence  of  bits> 

<sequence  of  bits> 
<sequence  of  bits> 
<sequence  of  bits> 


There  are  six  print  commands  in  TESLA  (c.f.  paragraph  2.3-^)'   They 
are  in  one-to-one  correspondence  with  the  object  language  commands 
(c.f.  Appendix  C  for  the  internal  coding  of  these  commands).   Note 
that  there  is  no  problem  in  using  for  the  printing  commands  codes 
which  are  identical  to  some  of  the  control  commands  because  they  are 
used  in  a  different  context;  they  appear  in  different  files  which  are 
retrieved  by  different  programs  at  different  times. 
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The  TESLA  print  command  may,  or  may  not,  include  case 
limits,  e.g., 

PRIEr2  GRPl,  GRP2; 
or  ERIWT2  [l:l6]  GRPl; 

Hence  the  print  command  "block  issued  hy  the  translator  must  include: 

the  object  code  for  the  command; 

the  group  names;  - 

the  cases  for  which  the  printout  is  desired; 

the  symbolic  representation  of  the  signals  in  the  group. 
The  groups  are  printed  in  the  same  order  in  which  they  appear  in  the 
TESLA  program.   This  is  all  that  is  needed  for  the  commands  PEINT2 
and  PRINTS. 

If  the  command  is  a  PRAC  or  a  PRID,  then  the  expected 
outputs  must  he  saved  as  comparison  information.  Therefore  a  print 
command  block  has  the  appearance  shown  in  Figure  22,  where  Ql  contains 
the  number  of  signal  values  to  be  printed,  and  Q2  contains  the  number 
of  characters  in  the  group  name.  The  number  of  signals  in  the  group 
to  be  printed  comes  from  the  header  word  of  the  block  corresponding 
to  the  groups  in  the  group  array.   Such  a  block  has  to  be  put  out  for 
each  group  appearing  in  the  print  command,  which  means  that  the 
command  verb  has  to  be  repeated  for  each  group  to  be  printed. 

The  printout  control  language  also  includes  the  two  verbs 
EOI  and  EOF,  which  have  the  same  function  and  format  as  in  the 
simulator  input  language.  EOI  is  to  be  issued  when  the  output  file  is 
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12 


case 
47' 


^ 


Q2 


26 
Verb 


3^^ 


^7 


Ql 


Case  mask   (PKEMMASK) 


0  I  0 


0  '  0 


G  I    R  1    0 


U  '  P 
— I 


Id  ;  b 


20 


E 


34 


^ 


smBi 


SYiy[B2 


smB3 


z 


^ 


SYMB^ 


SIMB5 


SYMB6 


U  -y^N 


-case  1 

even  number  of  full  computer 
words  containing  the  name  of 
the  group  as  it  appears  in 
BIGTAB  (i.e.  6  characters  per 
word) 

list  of  the  SYMBOLS  of  the 
variables  in  the  group, 
packed  3  per  word  (filled  with 
0 ' s  to  make  an  even  number 
of  words) 

Expected  outputs  in  the  case 
of  PRAC  or  PRID  (filled  up 
with  O's  if  necessary  to  make 
an  even  number  of  words 
always ) 


Figure  22.   Format  of  a  Print  Command  Block 


completed  at  the  end  of  the  test  step.   EOF  is  to  be  issued  when  the 
output  file  is  completed  at  the  end  of  the  whole  program.   In  fact 
the  EOT  and  the  EOF  blocks  are  issued  at  the  same  time  for  the 
simulator  input  and  the  printout  control. 
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5 .   CONCLUSION 

Two  files  are  built  by  the  TESLA  Translator.  These  are  the 
file  input  to  the  simulator  called  TESLA/SINHJT  and  the  print  control 
file  TESLA/FRINTC.   The  translator  has  been  tested  on  a  number  of 
test  programs  but  not  yet  on  long  real  simulations  because  of  delays 
in  the  implementation  of  the  simulator  itself. 

On  a  60  card  program,  the  compilation  speed  was  208  cards 
per  minute.   But  the  T¥S  implementation  requires  a  fixed  amount  of 
time  for  initialization  which  is  independent  of  the  length  of  the 
program.   Thus  for  longer  programs,  the  effective  rate  of  compilation 
is  increased.  For  instance,  a  120  card  program  was  compiled  at  the 
rate  of  273  cards  per  minute. 

There  exists  another  factor  which  affects  the  running  speed; 
this  is  the  fact  that  the  TESLA  Translator  runs  on  a  B5500  on  which 
program  speeds  are  heavily  dependent  upon  the  mix  of  programs  in  the 
system.   Because  of  certain  language  features  and  because  the 
Translator  is  tightly  linked  to  the  simulator  in  its  design  (the 
translator  performs  at  compile  time  those  operations  completely 
defined  then),  the  TESLA  translator  deals  with  large  arrays,  hence 
making  heavy  use  of  the  l/O  channels  to  exchange  information  between 
core  memory  and  the  B5500  disks.   Therefore,  if  the  mix  contains 
another  program  also  requiring  heavy  use  of  the  l/O  channels  the 
performance  of  the  system  is  significantly  reduced. 
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More  use  of  the  system  is  necessary  before  its  performance 
can  "be  evaluated^  but  the  translator  itself  already  has  been  of  some 
use.   It  has  been  used  to  test  some  CU  boards  and  in  testing  the 
accuracy  of  the  simulator -generator  itself.   TESLA  allows  a  clear 
specification  of  the  inputs  to  signals^  then  by  following  the  trace 
and  propagation  of  these  signals  on  the  blueprints  of  certain  known 
circuits,  it  is  easy  to  check  the  real  output  of  the  board  against 
the  output  given  by  the  simulator- generator.   This  procedure  has  been 
a  great  help  in  the  debugging  of  the  simulator-generator. 

The  systematic  test  of  the  CU  boards  cannot  be  undertaken 
before  thorough  debugging  of  the  translator  simulator  system  as  a 
single  entity.  More  thorough  experience  in  the  use  of  these  programs 
will  be  necessary  to  really  appreciate  their  usefulness  and 
performance  but,  as  far  as  can  be  ascertained,  they  appear  to  serve 
the  purpose  for  which  they  were  designed. 
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APPMDIX  A 


THE  SYN1AX  SPECIFICATION  OF  TESLA 
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THIS  IS  THE  SYNTAX  SPECIFICATION  ^f    TESLA  IN  6NF 
FOR  INPUT  TO  THE  ILLIAC  IV  TRANSLATUR  WRITING  SYSTEM  ; 
<PROGRAM>  It*  fREGIN  <SIMULATION  CASES>  »l  <COMPOUND  TAIL>       J 
<COMPOUN0  TA1L>  lt«  <PROGRAM  ELEMENT  LISl>  <END.  «2    J 
<PROGRAM  ELEMENT  LIST>  M«  <PROGRAM  ELEMtNT>  / 

<PROGRAM  ELEMENT  LIST>  <PROGRAM  ELEMENT>  I 

<PROGRAM  ElEMENT>  ll«  <DEClAKATION>  »J       / 

<SIMULATI0N  C0NTR0LS>  <TFST  STEP>  #3    I 
<SIMULATI0N  CASCS>  M»  iCASES  t<LOWEH  LIMIT>I<UPPER  LIMIT>J  #4    I 
<LOWER  LIMIT>  H«  <*N>  #5    J 
<UPPER  LIMIT>  ll«  <*N>  »6    ; 

<OErLARATION>  ll»  KGROUf*  DECLARATION>       / 

<DIGIT  DECLARATION>       / 
<UATA  DECLARATIQN>       J 

<riRnUP  f)ECLAHATlON>  ll«  <GROUP  TYPE>  IGRUUP  <GR01JP  ASSIGNMENT>      / 

<GROUP  TYPE>  <GRUUP  ASSIGNMENT>       / 

<GROUP  declaration>  $,   <grouh  assignment>     I 

<OATA  DFCLARATinN>  !!■  «DATA  <DATA  ASSIGNMENT>        / 

<DATA  DECLARATI0N>  i#  <nATA  ASSIGNMENT>       t 
<0IGIT  nECLAHATlON>  lt»  *UIGlT  #100  <0I6iT  AssIGnMENT>       / 

<OIGIT  DECLARATION>  tf    flOU  <DIGIT  ASSIGNMENT>       J 
<GRnuP  TYPE>  II*  ISIGNAL  97         / 

iSTORAGE  #8    I 
<GROUP  «SSIGNMENT>  ll«  <GROUP  OESI GNAT0R>«1 7  •  (<SIGNAL  LIST>)  #9  / 

<GR0UP  OESIGNATOR>  #17  C<SlGNAL  LIST>)  #9  I 
<SIr,NAL  LlST>  ll«  <SIGNAL  LIST  ELEMENT>       / 

<SIGNAL  LIST>  #*  <SlGNAL  UST  ELEMENT>       i 
<SI6NAL  LIST  ELEmENT>  li»  <*I>  #10   ; 

<OATA  ASbI(iNMENT>  11*  <DATA  DESIGNAT0R>  ■  <BIT  PATTERN>  #11   / 

<DATA  0ESIGNAT0R>  <BIT  PATTERN>       J 
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<Olr,IT  ASSIGNHCNT>  li«  <CASE:  dependent  0i6lT>  a  «101  <BASe>  NOBACK 
<DIGIT  LIST  WITH  PAREN>  )  fl02  <WEPETITlON  FACTOR>  #12  t 

<CASE  DEPENDENT  OIGIT>  It*  <LETTER>  113   I 
<BASE>  II*  <>  / 

<*N>  #U   I 
<0I61T  LIST  NITH  PAREN>  tl«  (  ilOO  <OIGIi>  #15   / 

<DIGIT  LIST  WITH  PAREN>  <DIGIT>  #lb       i 

<REPETITION  FACTOR>  ll*  <>  / 

*  <*N>  #16  ; 

<GROUP  OCSIGNATOh>  tt«  <*I>  J 

<OATA  DESIGNAT0R>  H*  <*I>  #16   I 

<H1T  PAT1ERN>  It"  <BASE>  <8IT  PATTERN  LI^T  WITH  PAREN>  )  #102    j 

<BIT  PATTERN  LIST  WITH  PAREN>  il«  (  #100  <0IGIT>  #20   / 

(  #1U0  <CASE  DEPENOENI  DIGIT>  #21   / 
<BIT  PATTERN  LIST  WITH  PAREN>  <DIGIT>  #20   / 
<BIT  PATTERN  LIST  WITH  PAKEN>  <CASE  DEPENDENT  DIGIT>  #21   ; 

X******************  END  UF  DEFINITION  OF  <DECLARATlON>  *******♦*♦♦*****- 

<SlMuLATION  CONTkULS>  !«■  <StOuENCE  REPEHTION  SPEC  IF IC AT I0N> 

<STEP  RLPETiTlON  SPEC  IF ICAT 10N>       I 
<STEP  REPETITION  SPEC  I F I C AT ION>  ll«  <>  / 

IKEPtAT  <REPETITION  SP*-ClFIER>  #22   I 
<SEOUENCE  REPETITION  SPECI Fl C AT ION>  lis  <>  / 

#LUQP  <STEP  LABEL>  #23   ##  <REPETlTlON  SPECIFIER>  #24   / 
<REPETITION  SPEC1FIER>  ll«  <*N>        I 
<TEST  STEP>  H«  <STEP  LA8EL>  #25  #1       / 

<TEST  STEP>  <CONTHOL  STAIEmENT>  #i       i 

<STFP  LABEL>  H«  <*I>       I 
<C0NTHQL  STATLHENT>  II*  <ONES  ASSIGNHtNT>  / 

<2ER0S  ASSIGNMENT*  / 
<INPUT  ASSIGNMENT*  / 
<OUTPUT  FEEDBACK>  / 
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<OUTPUT  DISPLAY  SIATEMENT>  / 
<OUTPUT  COMPARISON  STATCMENT>  / 

<C0ND1TI0NAL  OUTPUT  DISPLAY  STATEMENT>  / 
<TRANSrER  STATEMENT>  / 
<N0CHANGE  statement>  / 

<STORAGE  ASSIGNHENT>  / 

<>  ; 

<0NE:S  ASSIQNHENT>  tl«  «INSET  #26  <30  f26   / 

fiNSET  «26   <INPUT  SPEC  IF ICAT I0NS>       J 
<ZCROS  ASSIGNMENT>  Its  «INCLR  127  #30  #20   / 

»INCLR  #27   <INPUT  SPEC  IF ICAT IONS>       I 
<INPUT  SPECIFICATIONS>  Ms  <INPUT  DESIGN*T0R>  #?8   / 

<CASE  LIMITS>  <INPUT  DESIGNATOR>  #29   / 

<INPUT  SPECIFICATIUNS>  •*  <CASE  LIMiTS>  <INPUT  DESIGNAT0R>  #29   I 

<TNPUT  n£SlGNATOF<>  Us  »ALL  #30   / 

<SIGNAL  LIST>  #31   j 

<CASE  LIMITS>  lis  (  <LOWER  LlMIT>  I  <UPPtR  LlMlT>  1  #32    j 

<INPUT  ASSIGNMENT>  Its  #INPUT  #33   <INPUl  GROUP  ASSIGNMENT>       / 

<INPUT  ASSIGNMENT>  #.  <INPUT  GRUUP  ASSIGNMENT>      I 

<!NPUT  GROUP  ASSIGNMENT>  Its 

<INPUT  GROUP  DESIGNAT0R>  <DATA  PATTERN  SpEC I Fl CATIONS>  #34   j 
<OATA  PATTERN  SPEC  IF  IC  AT  I  UnS>  lis  <DATA  >'ATTErn>  #35   / 

<CASE  LIMnS>  <DATA  PATTERN>  #30   / 

<DATA  PATTERN  SPEC  I FICAT IONS>  #'  <CASE  LlMlTS> 

<DATA  >'ATTERN>  #36   I 

<OATA  PATTERN>  IIS 

<L0GICAL  INVERSION  INDICAT0R>  <UATA  OESlGNATOR>  #37   / 
<L0GICAL  INVERSION  lNOICATOR>  <BIT  PATTERN>  #38  f 

<OUTPUT  rEEDdACK>  its  tiNOUT  #39   <FEEDBACK  ASSIGNMENT>  #40   I 

KOUTPUT  FEEOBACK>  it    <FEEOBACK  ASSIGNMENT>  #40   i 
<FEEOBACk  ASSIGNHENT>  II* 
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<INPUT  GROUP  0£SI6NAT0R>  <FEEOBACK  SPECIF ICATIONS>  f4i   I 
<rEEDBACK  SPECIFICATI0NS>  lt«  <OUTPUT  DAU  SPEC IFICAT IONS>  #42   / 

<CASE  LIMITS>  <OUTPUT  DATA  SPEC 4FICATI0nS>  1*3   / 

<FEEDBACK  SPECIFICATIONS>  ##  <CASE  LIMITS> 

<OUTPUT  OAIA  SPECIFICATI0NS>  #43   j 
<OUTPUT  DATA  SPECIFIC  AT IONS>  tl« 

<LO(ilCAL  INVERSION  IN0ICAT0R>  <UUTPUT  GROUP  DESIGNAT0R>  #44   I 
<LOGICAL  INVERSION  INDICAT0R>  »l«  <>  / 

iNUT  f'S   I 
<INPUT  G«OUP  DESHjNATOR>  lt«  <GROUP  DESH»NATOR>  #46    J 
<OUTPUT  GROUP  DE&IGNAT0H>  lt«  <GROUP  DESiGNATOR>  #47    I 

<TRANSFrR  STATEMENT>  ll»  f??t    #48   / 

#FFX  <CASE  LIMII  LIST>  #49   I 

<NOrHANGE  STATEMtNT>  lt«  «FFOLO  #50   / 

#FFOLO  <CASE  LIMIT  LIST>  #51  I 
<CASE  LIMIT  LIST>  ll*  <CASE  LIMITS>  #52   / 

<CASE  LIMIT  LIST>  »»  <CASE  LIMITS>  #53   j 
<STnRAGE  ASSIGNMENT>  tl«  #FFlN  #54   <ST0NAGE  GROuP  ASSIGNMENT>       / 

<STOhAGE  ASSIGNMENT>  #/  <SIORAGE  GROUP  ASSIGNMENT>      I 
KSJORAGE  GROUP  ASSIGNMENT>  l»« 

<fiHOUP  DESIGNATOR>  #55 

<DATA  PATTERN  SPEC  IF IC AT IONS>  #56   I 
<OUTPUT  DISPLAY  STATEMENT>  ll«  #PRINT2  #37  #59   / 

#PRINT8  #38  #59   ; 

#PRINT2  #37  <OUTPuT  SPEC  IF  I  CAT IONS>     / 

#PRINTB  #38  <0UTPUT  SPECI F IC ATIONS>     J 
<OUTPUT  SPECIFICaTIONS>  ll»  <OUTPUT  OESI*»NaTOR>       / 

<CASE  LIMITS>  <OUTPUT  UESI«»NATOR>       / 
<OUTPUT  SPECIFICATI0NS>  ##  <CASE  LIMITS> 
<OUTPUT  UESI^NATOR>       J 
<OUTPUT  DESI(iNATOW>  its  #ALL  #59   / 
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<OUTPUT  GROUP  LI«>T>       I 
<OUTPUT  GROUP  LIST>  lie  <GROUP  OESIGNATOK>  «60   / 

<OUTPUT  GROUP  HST>  *»    <GR0UP  OESIGNATOR>  #60       I 

<OUTPUT  COMPARISON  STATEMEnT>  li«  fPRAC2  #61  <EXPECTED  0UTPUT>       / 

fPKACe  #62  <EXPECTEO  OUTPUl>       / 

<OUTPUT  COMPARISON  STATEMENT>  ##  KfXPECTED  OUTPUT>  I 
<EXPECTEO  OUTPUT>  ll« 

<r,ROUP  OESIGNATOR>  #63  <DAIA  PATTERN  SPEC  IFICATI0NS>  #64j 
<C0NDITI0NAL  OUTPUT  DISPLAY  STATEMENT>  l»« 

#PhID2  #65  <EXPECTED  OUTPUl>       / 

#PHlDa  #66  <EXPECTEO  OUTPUl>       / 
<CUNDITIONAL  OUTPUT  DISPLAT  STATEMENT>  ## 
<EXPECTEO  OUTPUT>       I 

<LETTER>  ll«  A/R/C/D/E/F /G/H/I/J/K/L/M/N/O/P/Q/R/S/T/U/V/W/X/Y/Z   J 

<Dir,IT>  lis  0/1/2/3/4/5/6/7/8/9  i 
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APPENDIX  B 


A  SAMPLE  TESLA  PROGRAM 


S  RSWD  TIMES  ^^ 

62 

BEGIN 

CASES  (1I32]I 

SIGNAL  GROUP  INIA  ( ABT-12--G0* ABT-28--G0)*  IN2A  (ABT-29— 60)1 

STORAGE  GROUP  STO  (TR0-12--L1#TR0»13— Ll)> 

SIGNAL  GROUP  IN3  ( ABT-**--G0)l 

DIGIT  A  a  2(0n*16'  B«6(0i234b67)*4l 

SIGNAL  GROUP  BIGONE  ( ABT-28--60#TR0-12— Ll  *  ABT-**— 60#  INI  A  )| 

DATA  PAT1  ■  2C010101)#  PAT2«2( OAl AOAl A } I 

DATA  PAT3b6(0B162B3B4BSB6B7B}J 

STEPII 

INSET  INIA  I 
STEP2I 

INSET  IN3  I 

STEP3I 

FFIN  STO  PAT2  f 
STEPai 

INSET  Att0-**--60i 
STEP5I 

INCLR  AS0-**--G0i 

STEPdl 

FFOLDI 
STEP7I 

INPUT  iNlA  2(11)1 
STEPSI 

INPUT  IN3  2C0101010101U10101)  I 


STEP9I  63 

PRINT2  INIAI 

REPEAT  3 
STEPlOl 

PRINT2  1N3; 
STEPllI 

PRINTS    IN1AMN?A*ST0»IN3; 
STEP12I 
STEP13I 

PRAC2    Tn3    2(010101U101U10101)J 

STEP14t 

PRIU8  INIA  8(55)   ; 
STEPIbl 

INSET  rni6J  iNi  ; 

STEP16I 

INCLR  AdT-**--GU  I 
STEP17I 

»NSLT  f  U8]  IN3  »  [17I24J  IN3  ; 
STEPlbl 

INPUT  IM3  CIiKS]  2(111U111U1111U)«  [i7|32]  ?  ( OUOOOOOOOOOOUUOO)  j 
REPEAT  3 
STEP19I 

INSET  ri7l321  In3  J 

InCLR  tltl6j  INi  t 

STEP20I 

INSET  [ll8J  iNlA  f     IN2A  ; 
STEP?ll 

INSET  I  ' 

STEP22I 

INCLR  I 
STEP23I 


6k 


PHINT2  J 
STEP24I 

PRINT2  ALL  t 
END, 


CONGRATULATIONS,   NO  SOUHCE  PROGRAM  ERRORS  wERE  DFTECTEO  IN  PASS  1 
THE  TOTAL  TIME  WAS    0  MINUTES  IA,6  SECONDS, 

TIML  FOK  INITIALIZATION!  U  MINUTES  3.6  SECONDS, 

TIME  FOR  SCANNING!  W  MINUTES  2,6  SECONDS, 

TIME  FOrt  PARSING!  W  MINUTES  4.«  SECONDS, 

TIME  FOK  SEMANTIC  ACTIONS!  «  MINUTES  *tl  SECONDS, 

TIME  FOR  EHROR  RECOVERY!  '<>    MINUTES  0,0  SECONDS, 

TIME  FOR  DEBUG  PRINTING!  W  MINUTES  0,0  SECONDS, 

60  CARDS  READ  AT   246  CARDS  PtR  MINUTE. 
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APPENDIX  C 


TABLES  OF  THE  INTERNAL  CODES  OF  THE  OBJECT  COMMANDS 


Tables  of  the  Internal  Codes  of  the  Object  Commands 


1.   Input  Control  Commands 
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Verbs 

Codes 

Octal 

Decimal 

FFl 
FF2 
FF3 
IWl 
JE2 
IN3 
inU 

EOF 

EOI 

001 
002 
003 
010 
Oil 
012 
013 
020 
021 

1 
2 

3 
8 

9 

10 
11 
16 
17 

Print  Control  Commands 


6? 


Verbs 

Co 

des 

Octal 

Decimal 

PRINT2 

ooU 

k 

PRINTS 

006 

6 

PRAC2 

010 

8 

PRAC8 

012 

10 

PR  102 

01^ 

12 

PRID8 

016 

Ik 

UNCLASSIFIED 
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